从库连接的账户密码以纯文本的形式存储在赋值的元数据信息表，或者文件中。由参数 master_info_repository =file/table启用gtid 相关信息保存在mysql.gtid_executed 表内 gtid_executed_compression_period 变量控制是否压缩表信息保存

GTID 由源的UUID和这个服务器上尚未使用的非零事务序列号组成。如果客户端事务未写入二进制日志(如只读事务…)则不会为其分配gtid

ln -s /usr /local/mysql5.7/bin/mysqlbinlog /usr/local/bin/mysqlbinlog mysql

mysqlbinlog 默认读取 /etc/my.cn 配置文件 ，为避免 未知字符集问题 需注释[cline] 下的默认字符集 参数

mysql 支持两种复制方式 ，1 基于语句的复制 2 基于行的复制 （与binlog的记录格式相关） 在主库记录二进制日志，在备库重放二进制日志 。在同一时刻无法保证主从数据的一致，一些大的语句可能导致备库产生较大的延迟 。mysql 复制大部分是向后兼容的，新版本服务器可以作为老版本的备库，但反过来不一定可行，因为其可能无法解析新版本采用的新特性或语法。复制带来的开销： 通常每个备库会对主库增加一些负载（如网络IO开销），尤其当备库从主库读取旧的二进制文件时，可能造成更高的IO开销，

通过复制可以将读操作指向备库来获取更好的性能，但对于写操作，除非设计得当。否则不适合通过复制来扩展写操作。在一主多从环境下，写操作会被执行多次，这个时候系统性能取决于写入最慢的部分 。

复制解决的问题： 1 数据分布 2 负载均衡 3 备份 4 高可用性和故障切换 5 mysql升级次测试

复制基本： 在主库上记录binlog 将主库binlog发送到从库成为从库的中继日志 ， 从库回放中继日志 。涉及 主库写 binlog 线程 ，从库获取主库binlog IO线程， 从库回放sql sql线程。IO 线程能够独立于 SQL线程工作，允许这两个线程一步进行。复制架构的限制 ： sql线程只有一个，获取到主库的事件在备库上却只能串行执行。 这是许多工作的性能瓶颈所在。虽然有些针对该问题的解决方案 但大多数然受限。

配置复制： 1 创建具有权限的账户 ， 2 配置主库，从库。 3 通知备库连接到主库并启动主从线程开始复制

1 创建复制账户 CREATE USER ‘repl’@’%.example.com’ IDENTIFIED BY ‘password‘; GRANT REPLICATION SLAVE ON . TO ‘repl’@’%.example.com’;账户最少需要 REPLICATION SLAVE 权限 读取 binlog 2

推荐的安全复制配置 ： sync_binlog =1 mysql 每次在事务提交前都会将binlog同步到磁盘 。 保证服务崩溃时不会丢失事件。innodb_flush_logs_at_trx_commit =1 ；skip_slave_start; sync_master_info =1 从库执行一个事件 即将,master_ifo 信息写入磁盘 ；sync_relay_log_info =1 ；sync_relay_log =1 .relay_log_purge 控制是否删除不需要的relay_log .

复制的原理 ：基于语句的复制 模式 ，实际上是把主库上执行的SQL 在备库上再重做一次 。 优点： 实现相对简单，理论上简单记录和执行语句，能够让主备同步一致， 二进制内的事件更加紧凑。基于语句的模式复制不会使用太大的带宽。同时 mysqlbinlog 也最适宜基于语句的二进制工具。遇见复制的问题时 更好知道问题的源头 问题 ： 语句的执行还依赖其他因素，如SQL语句的执行时间，数据的元数据信息，一些无法正确复制的语句 如 current_user() 等，触发器，函数，存储过程在基于语句的模式下可能存在问题。 非确定性行为都难以复制 。 另外备库上更新是串行的 这可能需要更多的锁。 不是所有存储引擎都支持这类复制 。

基于行的复制模式 可以正确的复制每一行，一些语句可以被更加高效地复制 。 由于没有那种模式对所有情况都是完美的，可根据情况设置会话级变量 binlog_format 控制二进制日志格式 。问题： 由于语句并没有在日志内记录，因此无法判断执行了那些SQL，备库使用一种完全不同的方式进行数据变更，而不是执行sql . 因此当出现问题时可能很难找到问题所在 。

复制文件 ： mysql-bin.00000X mysql-bin.index(mysql依赖这个文件，识别二进制文件) mysql-relay-bin-inedx; master_info: 保存备库连接主库的信息； 不能删除，否则备库重启将无法访问主库，这个文件同时以文本方式复制了用户密码，需注意文件访问权限 。 relay-log-info 包含当前备库复制的二进制日志和中继日志的坐标。 同样不可删除，否则备库重启后将无法获知从哪个位置开始复制，可能会导致重放已经执行过的语句。

复制过滤器 ： 1 主库端过滤需要记录的binlog binlog-do-db/binlog-ignore-db 2 备库端过滤需要重放的relay-log replicate-ignore-db/replicate-do-db/replicate-wild-do-table/replicate-wild-ignore-table/replicate-rewrite-db—replicate-ignore-db 忽略某些库的binlog 日志应用。—replicate-ignore-table 忽略某些表的binlog 日志应用。—replicate-do-db 应用某些库的binlog 日志。—replicate-do-table 应用某些表的binlog 日志。—replicate-wild-do-table 使用通配符来匹配那些应用binlog日志的表。—replicate-wild-ignore-table 使用通配符来匹配那些不能应用binlog日志的表。—replicate-rewrite-db，能够实现主库与从库数据库名称不同的复制，比如主库数据库名为A，从库数据库名为B，实现主库A到从库B的复制。

使用过滤复制需要非常慎重，更好的办法是阻止一些语句记录binlog 使用 set sql_log_bin =0 ;

复制拓扑：可在任意个主备库间建议复制，但每一个备库